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Abstract 
This document describes the Vouch By Reference (VBR) protocol. VBR 
is a protocol for adding third-party certification to email. It 


permits independent third parties to certify the owner of a domain 
name that is associated with received mail. 
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Les 


Introduction 


Vouch By Reference, or VBR, is a protocol for adding third-party 
certification to email. Specifically, VBR permits independent third 
parties to certify the owner of a domain name that is associated with 
received mail. VBR may be performed anywhere along the email transit 
path, by any capable receiving module, either within the handling 
service or by end-user software. 


VBR accomplishes this with a two-part protocol: 


o In the first part, a sender affixes VBR information to email 
messages. The VBR information says which domain certification 
services the sender believes will vouch for email traffic 
associated with that sender. 


o In the second part, the receiver queries one or more certification 
services to obtain information about the identity that has been 
associated with a received message. This latter protocol uses the 
DNS to distribute the certification information. 


A sender provides certification attestations through the use of a new 
RFC 5322 ([RFC5322]) mail header field, "VBR-Info:". This header 
field contains the names of services that the sender claims will 
vouch for it, and the particular type of content of the message. A 
queried, third-party, DNS-based certification service can respond 
with a list of the types of message content it will vouch for, such 
as "transactional mail from somebank.example" and/or "all mail from 
anotherbank.example". 


A prerequisite for successful VBR operation is validation of the 
identity associated with the message. VBR is based on the use of 
domain names as identifiers, and permits multiple methods of 
obtaining and validating domain names. The validation methods are 
described in the "Obtaining a Useful Domain Name" section below. 


The sender performs two steps: 
1. Adds a VBR-Info header field to its message 
2. Protects the message, as appropriate 


If a recipient uses the results of vouching to adjust spam scores on 
incoming email, that recipient is placing a great deal of operational 
trust and power in the vouching service. Therefore, recipients need 
to select such services with care. Further, such recipients may want 
to select more than one vouching service in order to avoid a single 
point of failure for setting spam scores. 
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1.1. Definitions 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. Use of the VBR-Info Header Field 
A sender uses VBR to indicate which domain certification services the 
sender believes will vouch for a particular piece of mail. The 
certification service uses VBR to state for which signatures it will 
vouch. This protocol uses the DNS to distribute the certification 
information. 
A message may have multiple VBR-Info header fields. This means that, 
in the terminology of RFC 5322, VBR-Info is a "trace header field" 
and SHOULD be added at the top of the header fields. 
The content of the VBR-Info header field is a list of three elements: 


o The accountable domain 


o The type of content in the message 


o A list of domain names of services that the sender expects to 
vouch for that kind of content 


The accountable domain is given as md= followed by a domain name. 

The content type is given as mc= followed by a string; the defined 
values of that string are found below. The list of services is given 
as mv= followed by a colon-separated list of domain names. 

The formal syntax of the header field is defined in Section 4. 


3. Validation Process 


A message receiver uses VBR to determine certification status by 
following these steps: 


1. Extracts the domain to certify and the type of message content 


2. Verifies legitimate use of that domain using one or more 
authentication mechanisms as described herein 


3. Obtains the name of a vouching service that it trusts, either 
from among the set supplied by the sender or from a locally 
defined set of preferred vouching services 
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4. Queries the vouching service to determine whether the vouching 
service actually vouches for that type of content for that 
domain. 


4. The VBR-Info Header Field 
The VBR-Info header field has the following format: 
VBR-Info: md=<domain>; mc=<type-string>; mv=<certifier-list>; 


where <domain> is the domain for which vouching is offered, <type- 
string> is the content type of the message, and <certifier-list> is a 
list of domain names of certification providers that the sender 
asserts will vouch for this particular message. The structure of the 
<certifier-list> is one or more domain names with a colon (":") 
between each. The elements in the <domain>, <type-string>, and 
<certifier-list> must not have any white space in them. 


For example, assume that the signer has two companies that are 
willing to vouch for its transactional notices: certifier-a.example 
and certifier-b.example. The signer would add the following to the 
header of its outgoing message. 


VBR-Info: md=somebank.example; mc=transaction; 
mv=certifier-a.example:certifier-b.example; 


All three header parameters in the VBR-Info header are mandatory. In 
particular, there is no default for the md= domain. 


Upper and lowercase characters in a VBR-Info header field are 
equivalent, although conventionally the contents are all in lower 
case. For upward compatibility, verifiers MUST accept the fields in 
any order and SHOULD ignore any fields other than the three defined 
here. 


If a message has more than one VBR-Info header field, verifiers 
SHOULD check each in turn or in parallel until either a satisfactory 
certifier is found or all the header fields have been checked. All 
of the VBR-Info header fields in a single message MUST have identical 
mc= values. 


4.1. Syntax of VBR-Info Header Fields 
In the ABNF below, the ALPHA and DIGIT tokens are imported from 


[RFC5234], and the FWS and domain-name tokens are imported from 
[RFC4871]. 
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vbr-info-header = "VBR-Info:" 1*([FWS] element [FWS] ";") 
element = md-element / mc-element / mv-element 

md-element = "md=" [FWS] domain-name 

mc-element = "mc=" [FWS] type-string 

type-string = "all" / "list" / "transaction" 

mv-element = "mv=" [FWS] certifier-list 

certifier-list = domain-name *(":" domain-name) 


5. DNS Query 


When a recipient wants to check whether a certification claim is 
valid, it compares the list in the message to the list of services it 
trusts. For each service that is on the intersection of the two 
lists, it marshals a domain name to look up that consists of the 
following DNS labels (from left to right): 


o the domain name that asserts it can be certified 
o _vouch (a string literal) 
o the host name of the vouching service 


This domain name is queried for a DNS TXT record. The recipient 
looks up the domain name in the DNS in the exact same manner it looks 
up all other domain names. 


For example, if a message signed by somebank.example contained the 
VBR-Info header field above, the receiver might look up either or 
both of the following names, depending on which vouching service it 
trusts: 


somebank.example._vouch.certifier-b.example 
somebank.example._vouch.certifier-a.example 


If the DNS TXT record exists, it contains a space-delimited list of 
all the types that the service certifies, given as lowercase ASCII. 
For example, the contents of the TXT record might be: 


transaction list 


In the example above, the receiver checks whether or not either 
certifier vouches for "transaction" mail. That would be indicated by 
either of the following types: "all" or "transaction" ("all" 
indicates that the certifier vouches for all message types sent by 
the domain in question). If either of those types appear in either 
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TXT record, the certifier has vouched for the validity of the 
message. Of course, the recipient needs to ignore services that it 
does not trust; otherwise, a bad actor could just add an authority 
that it has set up so that it can vouch for itself. 


The name for the label _vouch was chosen because any domain name that 
includes it as one of its labels cannot be a valid host name. There 
will never be any accidental overlap with a valid host name. 

Further, it is safe to create a rule that says that a TXT DNS record 
that comes from a domain name that includes a _vouch label will 
always have the structure defined in this document. 


If the RDATA in the TXT record contains multiple character-strings 
(as defined in Section 3.3 of [RFC1035]), the code handling that 
reply from DNS MUST assemble all of these marshaled text blocks into 
a single one before any syntactical verification takes place. 


Verifiers MUST then check that the TXT record consists of strings of 
lowercase letters separated by spaces, and discard any records not in 
that format. This defends against misconfigured records and 
irrelevant records synthesized from DNS wildcards. 


The VBR record MUST have only one TXT record. 


This query method relies on the considerable advantages of existing 
DNS efficiencies, reliability, and experience. The lookup is very 
efficient, and certifiers Can add and delete client records as 
quickly as they want. The lookup also leverages the DNS's negative 
caching ([RFC2308]). 


6. Types of Message Content 


This section describes the types of content for which a certifier can 
vouch. While the rest of the VBR specification is mostly technical 
and precise, describing the types of contents in mail messages is 
inherently open to interpretation. Thus, this section makes 
distinctions as specifically as possible, but the reader needs to 
understand that these semantic definitions can be interpreted in very 
different ways by different people. 


Note that the value in the mc= element is self-asserted. The purpose 
of this element is for auditing. There will likely be cases where a 
certifier will vouch for one type of a sender’s mail (such as 
transactional mail) but not another type (such as advertising). A 
sender who cannot get anyone to certify its advertising mail, but has 
a certifier for its transactional mail, might be tempted to cheat and 
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mislabel it as transactional. The mc= element creates an the audit 
trail to help their certifiers catch such cheating and allow the 
removal of the certification for the transactional mail. 


Three types of content are defined. 
6.1. All 

"all" means all mail from the sender. 
642%. ISE 


"list" is the category for email sent to multiple recipients where 
each piece of mail is identical or is very similar to the others. 


6.3. Transaction 


"transaction" is the category for transactional messages. This is a 
response to a specific action of the user, or a notice about an event 
in the user's account at the sender. 


7. Obtaining a Useful Domain Name 


VBR relies on having a domain name that specifies a party that is 
accountable for the message. This requires obtaining the domain name 
and possessing a strong basis for believing that the use of the 
domain name is valid, that is, that it has not been spoofed. 


There are different ways to achieve this and this section discusses 
the allowed mechanisms. Senders SHOULD use Domain Keys Identified 
Mail (DKIM) (and MAY use DomainKeys, Sender Policy Framework (SPF), 
or SenderID) to give an accountable identity for the sender. 


7.1. DKIM 


DomainKeys Identified Mail (DKIM), [RFC4871], defines an accountable 
identity by associating a domain name with the message. It provides 
assurance that the association is valid through a public-key-based 
authentication mechanism. 


o When DKIM is the validation mechanism, VBR’s md= MUST match the 
domain name taken from one of the DKIM-Signature header fields. 
If the DKIM signature contains an i= field, the domain name from 
that field is used; otherwise, the domain name from the DKIM 
signature d= field is used. 
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o The VBR-Info header field SHOULD be included in the set of header 
fields protected by DKIM to prevent a malicious party from 
changing the contents of the VBR-Info header field or adding bogus 
VBR-Info header fields. 


o The VBR-Info header field SHOULD be added in the header 
immediately below the corresponding DKIM-Signature header field. 


If the DKIM signature validates, the domain name taken from that 
signature is valid for use with VBR. 


7.2. DomainKeys 


DomainKeys (DK), [RFC4870], defines an accountable identity by 
associating a domain name with the message in the d= tag of the 


DomainKey-Signature header field. It provides assurance that the 
association is valid through a public-key-based authentication 
mechanism. 


o When DomainKeys is the validation mechanism, VBR’s md= MUST be the 
same value as the domain name found in the DomainKey-Signature d= 
parameter. 


o The VBR-Info header field SHOULD be included in the set of header 
fields protected by DK to prevent a malicious party from changing 
the contents of the VBR-Info header field or adding bogus VBR-Info 
header fields. 


o The VBR-Info header field SHOULD be added immediately below the 
corresponding DomainKey-Signature header field. 


If the DomainKeys signature validates, the domain in the d= tag is 
valid for use with VBR. 


Ws Dis SPF 
Sender Policy Framework (SPF), [RFC4408], defines an accountable 
identity by using an existing message address and querying the DNS to 
discover whether it is valid for SPF use. 
When SPF is the validation mechanism, VBR’s md= MUST be the same 
value as the domain name in the <reverse-path> address that is the 


first parameter to the SMTP MAIL command. 


A domain is valid for use with VBR only when the SPF process produces 
a "pass" result. 
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Tudo Sender ID 


Sender ID, [RFC4406], 


VBR 


April 2009 


defines an accountable identity by using an 


existing message address known as the Purported Responsible Address 


([REC4407]) and querying the DNS 
Sender ID use. 


When Sender ID is the validation mechanism, 


to discover whether it is valid for 


VBR’s md= MUST be the 


same value as the domain name in the Purported Responsible Address in 


the message. 


A domain is valid for use with VBR only when the Sender ID process 


produces a "pass" result. 


8. Security Considerations 


VBR is used to allow users to trust independent third parties to 
certify the owner of a domain name that is associated with received 


mail. 


The party validating the mail might use that trust 


relationship to perform actions that affect the security of their 


system. 


The receiver of a message with a VBR-Info header field MUST ignore 


certifiers that it does not trust; 


add an authority that it has set 
Implementations SHOULD limit the 
they process in a single message 


a make-work or denial-of-service 


9. IANA Considerations 


otherwise, a bad actor could just 
up so that it can vouch for itself. 


number of VBR-Info header fields 
in order to protect themselves from 
attack. 


IANA registered the VBR-Info header field in the Message Header 


Fields Registry ([RFC3864]) 


Header field name: VBR-Info 


Applicable protocol: mail 


as follows: 


Status: standard 
Author/Change controller: IETF 
Specification document(s): RFC 5518 


Related information: none 
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